POV-Ray : Newsgroups : povray.programming : cleaning source code from warnings troubles : Re: cleaning source code from warnings troubles Server Time
28 Jul 2024 16:28:59 EDT (-0400)
  Re: cleaning source code from warnings troubles  
From: Warp
Date: 1 Oct 2002 21:27:26
Message: <3d9a4b7e@news.povray.org>
ABX <abx### [at] abxartpl> wrote:
> #define FOURCHARS_TO_INT(c1,c2,c3,c4) \

  Just to clarify things:

  I completely agree with Thorsten that this is bad. You should not make
ugly hacks in order to avoid a warning which you *know* is irrelevant for
the code in question. I completely oppose this suggestion.
  If you can get rid of a warning in a way that: a) does not actually
modify the actual code, but simply adds extra unambiguating syntax to
it (such as extra parentheses to unambiguate an expression) and b) makes
the code cleaner and clearer, then it may be ok to do it.
  However, if you are going to actually modify how the code works just
to get rid of an irrelevant warning, and the resulting code is uglier,
clumsier and even more dangerous, then that's definitely a no-no.

  So I fully agree with Thorsten with this.

  However, what I strongly disagree with is that gcc is somehow "broken"
or is a bad compiler because of this warning.
  The warning may be irrelevant in *this specific case*, ie. the POV-Ray
code, but that does not mean it's *always* irrelevant in all cases which
exist in the world.
  I also disagree with the idea that a compiler should not issue any
warnings about code which is correct according to the C++ syntax definition.
The fact that a piece of code is syntactically correct does not mean that
it works ok. That's exactly what warnings are for: To inform you that
the piece of code you just wrote might not work as you want. The warning
might be irrelevant in some cases, but it still can be of great aid in
many cases.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.